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INTRODUCTION 


This  digest,  produced  by  INPUT  for  Agence  De  L'Informatique,  reviews  applied 
trends  in  the  United  States  Software  Engineering  field. 

Software  Engineering  was  selected  as  a  topic  because  it  is  a  key  component  in 
(and  frequent  barrier  to)  the  satisfactory  application  of  business  information 
to  the  decision-making  and  control  processes  of  government  and  industry. 

In  contrast  to  previous  reports  in  this  series,  there  is  little  by  way  of  a 
concentrated  driving  factor  that  forces  organizations  to  adopt  new  engineering 
techniques  and  approaches  to  the  process  of  developing  and  maintaining 
software. 

Except  for  the  organizations  that  do  software  contracting  directly  with 
federal  government  agencies,  government  regulation  does  not  play  a 
significant  role  in  this  field,  nor  does  competitive  pressure. 

Basic  economic  factors  may  be  a  motivating  influence,  but  most  likely 
is  the  growing  concern  with  improving  productivity  in  all  facets  of  U.S. 
production  (not  just  software  production). 

Consequently  the  topics  to  be  discussed  in  this  digest  are  organized  under  the 
headings  of: 


Goals. 


Techniques. 
Future  directions. 
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II  GOALS 


A.  BACKGROUhO 

o  The  term  "Software  Engineering"  came  into  being  during  the  late  i960s  as  part 
of  a  desire  to  transform  the  somewhat  mysterious  and  highly  individualized  art 
of  computer  programming  into  a  more  predictable,  controllable,  and  mea- 
surable discipline. 

The  underlying  reason  for  this  change  in  direction  was  a  growing 
number  of  failures  by  EDP  organizations  to  achieve  software  design 
goals  in  the  face  of  vastly  increased  levels  of  complexity  in  systems 
requirements. 

•  As  a  result,  increased  attention  from  the  academic  community  and  from  the 
"front-line"  practitioners  in  the  aerospace  industry  (who  were  most 
immediately  affected  by  the  failures)  began  to  be  placed  on  determining  and 
defining  the  principles  and  characteristics  that  contributed  to  successful 
software  project  implementations. 

•  Earlier  software  metrics  of  success,  such  as  development  time,  development 
cost,  consumption  of  hardware  resources,  and  short  term  performance  statis- 
tics began  to  give  way  to  the  longer  term  criteria  of  maintainability, 
reliability,  and  life  cycle  costs. 

•  Three  independent  lines  of  attack,  each  addressing  a  different  set  of  goals, 
were  initiated  during  the  1970s: 

Interactive  development  of  systems,  to  reduce  the  time  delays 
associated  with  the  correction  of  small  errors  in  coding  or  keypunching, 
that  impeded  the  orderly  progress  of  systems  development. 
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Data  base  management  systems  (DBMS),  which  were  intended  to  reduce 
the  costs,  conflicts  and  contradictions  inevitably  associated  with  redun- 
dant data  systems  that  are  separately  maintained. 

B,  DESIGN 

I.       STRUCTURED  DESIGN  TECHNIQUES 

•  The  realization  that  came  from  the  latter  two  approaches,  namely,  that  data 
and  logic,  or  data  flow  and  control  flow,  can  and  ought  to  be  kept  separate, 
formed  the  basis  for  a  whole  new,  rigorous  approach  to  systems  design, 
commonly  referred  to  as  "structured  analysis,"  "data  flow  analysis,"  or  "data 
structure  analysis". 

The  minor  differences  between  each  of  these  terms  need  not  be 
addressed  here. 

•  Eventually  "software  engineering"  came  to  comprise  the  technology  of  re- 
quirements and  specifications,  design,  programming,  verification  and  valida- 
tion, maintenance,  management,  and  software  economics. 

•  Although  there  are  some  similarities  to  hardware  engineering,  the  differences 
are  significant: 

in  software,  only  rarely  is  there  an  effort  to  develop  alternate  designs 
and  choose  the  best  one. 

Most  software  is  "one  of  a  kind,"  and  is  not  re-engineered  before  being 
put  into  production. 

In  other  words,  the  prototype  is  the  final  product. 
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Software,  therefore,  requires  much  greater  emphasis  on  quality 
assurance  early  in  the  design  process,  since  there  is  not  likely  to  be 
another  opportunity  to  revise  the  design. 

•  Recent  studies  conducted  by  INPUT  confirm  that  few  business  or  govern- 
mental organizations  have  yet  made  any  concerted  attempt  to  apply  the 
disciplines  of  software  engineering  to  the  production  and  maintenance  of  their 
own  internal  software,  and  even  the  commercial  software  vendors  have  been 
slow  to  adopt  software  engineering  techniques. 

•  There  is,  however,  a  growing  realization  that  additional  effort  devoted  to  the 
specification,  implementation,  and  testing  of  new  applications  software  while 
it  is  being  developed  can  contribute  significantly  in  reducing  the  future  efforts 
and  costs  that  must  be  devoted  to  maintaining  the  existing  body  of  software. 

•  The  intention  of  performance  improvement  in  software  development, 
therefore,  is  to: 

Isolate  and  identify  potential  problems  at  the  beginning  of  the  software 
development  cycle  where  they  are  easier  and  less  costly  to  fix  or 
prevent  (perhaps  at  one-tenth  to  one-hundredth  of  the  later  cost). 

Trade  increased  design  efforts,  and  possibly  increased  short  term 
operational  costs,  for  lower  lifetime  costs  stemming  from  a  reduction 
in  future  maintenance  requirements. 

•  The  problem  that  the  software  designer/manager  faces  is  how  to  define  and 
cope  with  program  and/or  system  complexity. 

Common  approaches  have  centered  around  the  techniques  of  hier- 
archical decomposition  (i.e.,  the  "top-down"  approach),  or  functional 
abstraction  (i.e.,  arbitrarily  simplifying  systems  by  considering  only  a 
limited  amount  of  detail  at  one  time). 
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Implicit  in  both  approaches  is  the  necessity  to  iterate  the  design 
process,  successively  refining  the  design  and  accommodating  greater 
detail  as  the  overall  structure  of  the  system  becomes  better  under- 
stood. 

•         Not  yet  adequately  addressed  by  any  of  the  formalized  design  techniques  are 
the  problems  often  faced  by  real  time  systems: 

Handling  concurrency. 

Coordinating  distributed  control  responsibilities. 
Timing-related  issues  in  general. 


C.       MEASUREMENT  AND  ESTIMATION 

•  A  second  topic  of  software  engineering  not  yet  adequately  addressed  is  the 
subject  of  measurement  and  estimation,  not  only  of  the  software  process,  but 
also  of  the  software  product. 

•  Techniques  currently  in  use  vary  all  the  way  from  no  estimates  or  measure- 
ments at  all,  through  guesses  by  the  project  leader  as  to  the  likely  duration  of 
a  project,  through  averaging  of  estimates  contributed  by  several  experienced 
staff  members,  through  algorithmic  computations  based  on  a  few  projections 
of  size,  complexity,  and  participant  skill  levels,  to  highly  complex  simulations 
of  cost  and  duration  incorporating  many  factors  of  the  system  and  the 
environment  in  which  the  software  will  be  produced  and  operate. 

■  -  Results  of  the  above  techniques  vary  widely,  of  course,  and  only  the 
first  two  have  achieved  widespread  use.  Credibility  of  results  is 
another  matter. 
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The  most  advanced  of  the  techniques  have  proven  to  be  fairly  accurate 
for  estimating  the  cost  of  certain  classes  of  systems,  and  offer  hope 
that  they  may  soon  be  refined  enough  to  gain  wider  credibility  and  use. 

Measurements  and  estimates  of  the  product-related  criteria,  such  as 
complexity  and  reliability,  have  not  advanced  as  far,  and  continue  to 
stir  much  controversy  when  they  are  attempted,  particularly  with 
respect  to  ordinary  business  systems. 

•  Weaknesses  of  the  present  models  and  techniques  for  predicting  cost, 
complexity,  and  reliability  include: 

Their  usual  focus  upon  lines  of  code  as  a  base  unit  (where  lines  of  code 
are  variably  defined). 

Their  frequent  inclusion  of  factors  in  the  equation  that  cannot  be 
determined  with  precision  until  late  in  the  development  process. 

Their  inclusion  of  subjective  terms  (such  as  "difficulty")  with  high 
weights  assigned  to  them,  which  makes  the  objectivity  of  the  entire 
equation  questionable. 

D.  TESTING 

•  The  third  area  of  software  engineering  that  is  currently  undergoing  a 
considerable  transformation  of  thinking  is  the  subject  of  how  to  ensure  that  a 
program  is  suitable  for  operational  use. 

•  Testing  of  suitability  ought  to  address  the  properties  of  reliability,  usefulness, 
performance,  and  robustness  (i.e.,  the  ability  to  respond  in  a  predictable  or 
sensible  way  when  subjected  to  conditions  for  which  the  software  was  not 
intended.) 
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•  Instead,  the  most  common  objective  of  testing  focuses  on  correctness,  largely 
because  there  are  as  yet  few,  if  any,  cost-effective  techniques  for  ensuring 
that  programs  do  meet  their  specifications. 

Up  to  50%  of  the  total  development  effort  has  been  reported  to  be 
spent  on  testing  and  debugging,  much  of  it  spent  in  somewhat  random 
and  intuitive,  but  non-directed,  activities. 

•  A  presumed  alternative  to  testing,  i.e.,  the  formal  proving  of  a  program's 
correctness,  has  not  been  either  an  efficient  or  an  infallible  approach. 

The  effort  required  to  prove  an  algorithm  correct  is  likely  to  equal  or 
exceed  that  of  the  total  development  effort  to  invent  and  program  the 
algorithm. 

Proving  the  correctness  of  algorithms  of  anything  more  than  trivial 
complexity  is  a  mathematically  formidable  undertaking. 

•  Nevertheless,  certain  situations  are  easier  or  less  costly  to  prove  correct  than 
to  test. 

The  accuracy  of  testing,  in  general,  in  ensuring  correctness  relates  to 
the  test  being  both  reliable  (i.e.,  consistent)  and  valid  (i.e.,  unbiased). 
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A,  DESIGN 

I.        STRUCTURED  DESIGN  TECHNIQUES 

•  The  acceptance  of  new  approaches  and  techniques  of  software  engineering  has 
been  relatively  slow  in  coming,  surprisingly  slow  in  a  field  which  is  itself  less 
than  thirty  years  old. 

No  doubt  this  is  due  to  the  exceedingly  personal,  intellectual  nature  of 
the  occupation  of  systems  analysis  and  programming. 

The  objective  of  the  new  techniques  has  sometimes  been  characterized 
as  "ego-less  programming"  for  this  very  reason. 

•  Because  of  the  psychological  difficulties  in  getting  the  new  techniques 
accepted,  less  than  a  third  of  all  the  software-producing  organizations  have 
made  any  concerted  attempt  to  adopt  them,  although  perhaps  two-thirds  of 
the  organizations  have  at  least  investigated  or  experimented  with  one  or  more 
of  them. 

These  numbers  will  grow  as  more  quantitative  "success  stories"  are 
published. 

Unfortunately,  since  many  of  the  benefits  from  the  use  of  these 
techniques  are  not  realized  until  years  later,  favorable  publicity  has 
been  mainly  speculative  to  date. 

•  A  large  number  of  "structured  methodologies"  for  requirements  analysis, 
system  specification,  overall  design  and  even  detail  (program)  design  have 
been  developed  over  the  past  ten  years  or  so.  They  include,  among  others: 
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Constantine/Yourdon/DeMarco  Structured  Design. 
Jackson's  Program  Design  Methodology. 
-  ■      Warnier-Orr's  Structured  Design. 

Gone  &  Sarson's  Structured  Design. 
Ross's  SADT. 
IBM's  HIPO. 

Franz's  Structured  Tableau. 

While  these  systems  differ  in  many  respects,  they  generally  share  several 
characteristics: 

They  are  related  to  structured  programming  in  some  way,  typically 
facilitating  the  use  of  the  constructs  of  sequence,  iteration  and 
selection  by  the  manner  in  which  they  define  the  output  of  the  analysis 
and  design  tasks. 

They  all  employ  some  graphical  system  of  representation  as  the  main 
vehicle  of  the  design,  documentation  and  review  (human  commun- 
ications). 

They  all  emphasize  top-down,  hierarchical  design  concepts. 

They  are  all  concerned  with  the  creation  of  logical  models  of  systems, 
answering  the  questions  of  "why"  and  "what",  rather  then  "how". 

With  the  exception  of  the  last  three,  all  others  take  the  flow  and/or 
structure  of  data  as  a  point  of  departure,  with  procedure  design 
following  directly  from  the  data  design  (e.g.,  Jackson)  or  being  comple- 
mentary to  it  (e.g.,  Warnier-Orr,  Gone  &  Sarson,  Yourdon,  et  a  I.). 

SADT  is  an  exception  in  that  it  gives  equal  weight  to  the  design  of  data 
structures  and  process  structures. 


•  HIPO  is  an  exception  in  that  is  concentrates  entirely  on  the  design  of 
procedures. 

•  Structured  Tableau  is  also  a  procedure-oriented  design  technique,  relying  on 
decision  tables  as  the  prinnary  graphic  tool. 

•  These  "structured  methodologies"  are  in  essence  intellectual  disciplines  or 
frameworks  for  the  analysis  and  design  tasks.  They  can  be  used  in  conjunction 
with  such  other  tools  and  strategies  as: 

System  development  methodologies;  e.g.,  SDM/70,  Pride/Logik,  etc. 

Organizational  techniques;  e.g.,  Chief  programmer  Team,  Egoless  pro- 
gramming. 

Review/interaction  techniques;  e.g.,  structured  walk-throughs. 
Data  dictionaries. 

Code  generators,  pseudo  code,  PDL,  etc. 
Requirements  languages;  e.g.,  PSL/PSA. 
Other  tools  and  aids. 

•  While  each  structured  methodology  claims  a  particular  set  of  benefits,  these 
benefits  can  be  generalized  for  the  group  of  methodologies  as  a  whole. 

Concentration  on  the  logical  requirements  and  structure  of  systems  in 
the  design  phase,  and  delaying  the  "how"  consideration  to  later  stages, 
results  in  more  robust  designs  that  reduce  the  need  to  make  major 
about-faces  later  on  in  the  life  of  the  system. 
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Use  of  graphical  descriptions,  with  their  meanings  nnore  precise  than 
natural  language,  promotes  clarity  in  communications  between  the  end 
users  and  developers,  among  the  development  team  itself,  and  between 
the  developers  and  the  maintenance  personnel. 

Use  of  top-down,  hierarchical  design  results  In  gradual  exposition  of 
detail,  which  makes  the  design  intellectually  manageable. 

o         By  the  same  token,  these  methodologies  also  share  some  common  problems. 

The  most  obvious  problem  is  that  substantially  more  time  is  spent  in  the 
analysis,  specification  and  design  phases,  creating  in  some  cases  user 
apprehension  and  management  impatience. 

Training  is  another  significant  problem.  While  the  mechanical  details 
of  most  of  these  methodologies  are  relatively  easily  mastered,  their 
effective  utilization  depends  on  a  radical  change  in  the  way  people 
think  about  systems.  This  change  requires  repeated  experience  and 
exposure  to  the  basic  principles  of  the  structured  methodology. 
Experienced  personnel  have  frequently  resisted  making  such  a  radical 
change. 

Finally,  these  methodologies  are,  in  effect,  imprecise  intellectual 
frameworks  that  leave  a  great  deal  to  the  ingenuity,  insight  and 
resourcefulness  of  the  designer.  That  is,  there  is  no  guarantee  that, 
given  the  same  problem,  any  two  designers  using  the  same  methodology 
would  follow  essentially  the  same  path  to  a  soloution,  or  even  that  they 
would  reach  the  same  solution. 

•  Nevertheless,  there  is  a  fairly  general  acceptance  among  the  U.S.  software 
producing  organizations  that  using  some  kind  of  structured  design  contributes 
to  better  quality  of  programs. 
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2.       REQUIREMENTS  LANGUAGES 


•  Requirements  languages  are  systenns  of  semantics  and  syntax  specialized  for 
describing  the  functional  requirements  of  systems,  especially  (but  not 
exclusively)  software  systems. 

These  are  not  simulation  or  modeling  languages;  they  deal  specifically 
with  the  description  of  requirements. 

•  The  motivation  for  the  development  of  such  languages  is  that,  by  casting  the 
system's  specifications  and  requirements  in  machine-parsable  form,  it  is 
possible  to  automate  several  important  aspects  of  the  functional  specifications 
process;  in  particular,  the  ability  to: 

Perform  certain  consistency  and  completeness  checks. 

Produce,  on  demand,  documentation  in  various  formats  that  reflect  the 
latest  state  of  the  design  process. 

Produce  progress  reports  automatically. 

•  Two  examples  of  requirements  languages,  along  with  the  computer  programs 
designed  to  process  the  "programs"  written  in  them,  are: 

PSL/PSA  (Problem  Statement  Language/Problem  Statement  Analyzer) 
from  the  ISDOS  (Information  Systems  Design  Optimization  System) 
project  at  the  University  of  Michigan. 

RSL/REVS  (Requirements  Statement  Language/Requirements 
Engineering  and  Validation  System),  developed  by  TRW  for  use  at  the 
Ballistic  Missile  Defense  Technical  Analysis  Center  (BMDTAC). 

•  In  some  respects,  BIAIT  (Business  Information  Analysis  and  Information 
Technology),  developed  by  Donald  C.  Burnstine  of  BIAIT  International,  can  also 
be  regarded  as  a  requirements  language,  although  it  is  not  automated. 
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PSL/PSA  appears  to  be  the  better-known  and  more  widely  used  of  the  three 
languages;  the  remainder  of  this  section  is  dedicated  to  a  brief  description  of 
PSL/PSA. 


•  PSL  is  a  language  for  describing  "systems". 

"Systems"  in  the  PSL  sense  consist  of  "things"  (objects),  which  may  have 
"properties"  associated  with  them. 

"Properties"  may  have  "property  values"  assigned  to  them. 

"Objects"  may  be  interconnected  or  interrelated  in  some  ways;  these 
connections  are  called  "relationships". 

All  of  the  above  are  very  general  and  could  apply  to  almost  any  system; 
to  particularize  this  for  an  information  system,  a  limited  number  of 
appropriately  predefined  objects,  properties  and  relationships  are  used. 

•  The  objective  of  PSL  is  to  describe,  in  machine-analyzable  form,  as  much  as 
possible  of  the  information  typically  found  in  functional  requirements  or 
overall  design  documents.  More  specifically,  PSL  recognizes  certain  types  of 
objects  and  relationships  that  permit  the  following  aspects  to  be  described: 

System  I/O  Flow:  the  interaction  of  the  system  with  its  environment. 

System  Structure:  the  hierarchy  of  objects  comprising  the  system. 

Data  Structure:  the  relationships  that  exist  among  data  items  used  or 
manipulated  by  the  system,  or  as  seen  by  the  end  users. 

Data  Derivation:  the  specifications  that  describe  which  data  are 
manipulated  or  used  by  which  processes,  and  how  the  output  data  are 
derived. 
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System  Size  and  Volume:  the  factors  that  influence  the  volume  of 
processing  the  system  will  do. 

System  Dynamics:  how  the  system  behaves  over  time. 

Project  Management:  identification  of  people  involved  and  their 
responsibilities,  schedules,  etc. 

o         PSA  is  the  computer  program  responsible  for: 

Parsing  the  PSL  "programs"  to  extract  the  appropriate  items  required 
for  all  other  PSA  functions. 

Storing  the  system's  description  in  a  data  base. 

Performing  consistency  checks. 

Producing  various  reports. 

•         The  reports  obtainable  from  PSA  include: 

Data  Base  Modification  Reports:  records  of  changes  made  to  the  data 
base  as  analysts  continually  enter  new  specifications,  requirements  and 
design  information. 

Reference  Reports:  displays  of  the  data  base  in  various  useful  formats. 
For  example: 

Name  List:  displays  all  objets  in  the  data  base,  along  with  their 
properties  and  the  date  of  the  last  change. 

Formatted  Problem  Statement  Report:  shows  all  properties  and 
relationships  associated  with  a  specific  object. 
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Summary  Reports. 

Data  Base  Summary  Report:  provides  project  management 
information  by  displaying  the  totals  of  various  types  of  objects  in 
the  data  base. 

Structure  Report:  displays  complete  or  partial  hierarchies  of 
objects. 

Picture  Report:  shows  the  data  flows  in  a  graphical  form. 

Analysis  Reports:  provide  various  types  of  analyses  of  the  information 
in  the  data  base.  For  example: 

Content  Comparison:  analyzes  similarity  of  outputs  and  inputs. 

Data  Process  Interaction:  shows  gaps  in  the  data  flows  and 
detects  unused  data  objects. 

Process  Chain  Report:  displays  the  sequence  of  events  and 
processes  in  the  system;  i.e.,  the  system's  dynamic  behavior  in  a 
graphical,  flow-chart  format. 

•         Some  of  the  advantages  of  PSL/PSA  are  that  it: 

Improves  the  quality  of  the  design  by  promoting  precision  in  the 
requirements  description,  and  by  performing  automatic  consistency  and 
deficiency  checks,  which  are  tedious  and  hard  to  do  manually. 

Permits  the  display  of  the  most  up-to-date  state  of  the  design  by 
organizing  the  system  description  in  a  data  base. 

Promotes  the  detection  and  early  removal  of  design  errors. 
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Probably  the  most  significant  current  disadvantages  of  PSL/PSA  are  that: 

PSA  maintains  a  private  data  base/data  dictionary,  which  is  separate 
from  the  target  system's  data  base/data  dictionary. 

The  system  is  currently  batch-oriented;  i.e.,  PSL  inputs  and  PSA  reports 
must  be  handled  as  batch  operations. 

The  use  of  formal  requirements  languages  in  the  U.S.  has  been  very  limited  to 
date,  but  they  have  received  high  praise  from  those  organizations  that  have 
made  the  effort  to  adapt  them  to  their  own  situations. 

Some  organizations  have  developed  their  own  computerized  interfaces 
to  PSL/PSA  to  enable  it  to  be  used  more  easily  in  conjunction  with 
other  design  tools. 

OTHER  TECHNIQUES 

Using  the  analogy  of  electronic  hardware  designers,  who  build  complex 
systems  from  commercially  available,  prepackaged  integrated  circuits  and 
other  components  which  perform  some  common  functions  in  a  standard  way, 
designers  of  software  systems  should  have  available  libraries  of  prepackaged 
basic  functions  from  which  more  complex  systems  could  be  built. 

There  has  recently  been  increased  interest  in  the  development  of  standardized 
software  modules  (i.e.,  "reusable  code")  to  perform  common,  business-oriented 
data  processing  functions. 

Kapur  &  Associates,  Inc.,  a  Danville,  CA,  consulting  firm,  has  been 
advocating  the  use  of  prepackaged,  standardized  modules  for  a  number 
of  years,  and  has  developed  packages  called  BUMP  (Building  Universal 
Model  Programs)  and  GENIUSS  (Generalized  Installation  Uniform 
Source  Statements). 


It  reports  50%  to  80%  productivity  improvements. 

Raytheon  Missile  Systems  Division  has  developed  a  system  of  pre- 
packaged, standard-function  modules  that  they  call  simply  "reusable 
code." 

It  reports  40%  to  60%  productivity  improvement. 

Raytheon  Service  Co.  is  in  the  process  of  turning  this  into  a 
commercially  offered  product,  probably  under  the  name  Universal 
Productivity  Package:  it  was  scheduled  for  release  in  the  last  half  of 
1980,  but  as  of  mid-October  the  system  had  not  yet  been  released. 

•  Both   Kapur   and   Raytheon   begin  by  noting  that  practically  all  business 
applications  can  be  classified  into  a  very  small  number  of  activity  types. 

Kapur  identifies  them  as  data  selection/edit,  data  extraction,  data 
update  and  report. 

Raytheon's  classification  is  data  select/edit,  data  sort,  data  update  and 
report.  It  excludes  sorting  from  the  UPP,  since  this  is  provided  as  a 
packaged  system  by  the  computer  manufacturer. 

•  In  the  Kapur  system,  the  standardized  modules  consist  of  common  logic 
structures  for  selected,  common  functions  such  as  sequential  file  update. 

These  logic  structures  are  expressed  in  terms  of  hierarchical  diagrams, 
Wamier-Orr  charts  and  Nassi-Schneiderman  charts. 

In  addition,  these  structures  are  partially  implemented  as  COBOL  and 
PL/1  programs,  with  several  items  left  open  for  the  programmer  to  fill 
in  for  the  particular  needs  of  the  application. 

o         The  Raytheon  system  has  about  1,500  prepackaged  modules,  of  which: 
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Some  are  completely  coded  into  "functional  modules"  (COBOL 
programs)  that  are  stored  in  a  central  library  and  can  be  retrieved  by  up 
to  five  levels  of  search  keys; 

Some  are  incompletely  coded  logic  structures,  with  areas  left 
undefined,  to  be  filled  in  as  required. 

The  Raytheon  system  also  includes  a  number  of  additional  tools: 

A  COBOL  reformatter  that  standardizes  the  COBOL  source  code 
generated  by  the  programmer  as  fill-ins  to  predefined  logic  structures, 
or  as  higher-level  code  calling  on  prewritten  functional  modules. 

A  test  data  generator. 

A  program  revision  control  system  for  maintaining  multiple  versions  of 
programs  in  development. 

A  debugging  tool,  a  file  comparison  tool  and  other  tools. 

Both  Kapur  and  Raytheon  report  remarkable  productivity  improvements, 
especially  for  entry-level  programmers. 

They  reach  a  high  level  of  productivity  in  three  months,  according  to 
Raytheon. 

Other,  obvious  advantages  of  the  reusable  code  system  include: 

Reduction  in  overall  (not  initial)  coding  effort. 

Reduction  in  maintenance  effort  because: 

Preceded  modules  that  have  been  used  a  number  of  times 
become  fully  tested. 


The  common  programming  style  of  precoded  and  semicoded  modules 
eases  the  task  of  understanding  "foreign"  code. 

•  Menu-driven  programming  is  INPUT'S  term  for  systems  in  which  some  or  all  of 
the  traditional,  procedure-oriented  programming  tasks  are  replaced  with  "fill- 
in-the-blanks,"  interactive  sessions  with  the  user. 

•  Conceptually,  menu-driven  programming  is  halfway  between  the  reusable  code 
approach  and  packaged  application  systems. 

It  generally  consists  of  group  of  skeleton,  prepackaged  tasks,  usually 
backed  by  a  data  base  management  system  and  an  inquiry/retrieval 
system. 

Through  the  interactive  sessions,  the  user  supplies  additional  speci- 
fications and  code  to  "flesh  out"  the  skeletons. 

The  term  "non-procedural  programming"  has  been  applied  to  menu- 
driven  systems  in  some  literature.  "Menu-driven"  avoids  confusion  with 
such  non-procedural  languages  as  SIMSCRIPT. 

9         Some  examples  of  menu-driven  programming  systems  follow: 

ADF  (Applications  Development  Facility)  is  an  IBM  lUP  (Installed  User 
Program)  that  creates  a  menu-driven  environment  in  conjunction  with 
IMS. 

DMS,  variously  known  as  Development  Management  System  or  Display 
Management  System,  is  available  in  several,  not  entirely  compatible, 
versions  for  the  8100  under  the  DPPX  operating  system,  the  3770  and 
3790,  and  DPD  operating  systems,  including  VM/CMS,  OS  versions  and 
DOS/VS.  It  creates  a  menu-driven  programming  environment  in  con- 
junction with  CICS/VS.  (The  8100  version  can  also  work  with  IMS/VS  at 
the  host). 
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TAPS  Transaction  Processor  (TTP)  from  Decision  Strategy,  Inc.,  now 
part  of  Informatics,  is  a  menu-driven  programming  system  available  in 
G  variety  of  versions  to  run  on  different  hardware  systems,  including 
IBM  (OS  and  DOS)  mainframes,  Interdata,  DEC,  HP,  Prime  and  Harris 
minicomputers. 

In  the  Wang  2200  and  VS  computers,  all  job  control  statements  have 
been  replaced  by  fill-in-the-blank  sessions  with  the  user  at  an  inter- 
active terminal;  application  coding,  however,  is  still  done  by  tradi- 
tional, procedural  coding. 

•  The  advantage  of  such  system  is  the  speed  and  ease  with  which  new 
applications  can  be  developed  and  changed,  frequently  cutting  weeks-long 
effort  to  a  matter  of  hours  or  days. 

•  The  disadvantage  is  that  the  prepackaged  skeletons  may  fit  only  a  certain 
class  of  problems.  Employing  user  exits  to  add  "own  code"  routines  invariably 
complicates  the  design  to  the  point  where  use  of  the  menu-driven  portion  is 
often  not  worth  the  effort. 

•  In  typical  use,  the  menu-driven  system  might  be  employed  for  the  class  of 
small  applications  to  which  it  is  best  suited,  while  major  systems  that  do  not 
fit  the  skeletons  well  are  developed  by  traditional  procedural  coding. 

Experience  will  show  where  the  dividing  line  should  be  placed. 

•  Reusable  code  has  not  yet  seen  widespread  acceptance,  but  menu-driven 
programming  is  rapidly  becoming  a  popular  technique  in  the  U.S. 
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B.       MEASUREMENT  AND  ESTIMATION 


•  The  shift  in  focus  that  occurred  in  the  early  to  mid-l970's  involved  a  shift 
from  the  process  of  software  development  to  the  management  of  software 
development. 

•  Concomitant  with  this  shift  came  an  emphasis  upon  being  able  to  quanti- 
tatively assess  the  sequence,  progress  and  performance  of  the  various 
activities  that  make  up  the  software  life  cycle. 

•  Quantitative  assessments  are  intended  to  make  the  development  effort  more 
visible,  and  thus  to  enable  feedback  to  be  applied  at  earlier  points  in  the 
development  sequence,  when  even  major  changes  in  direction  of  the  effort 
have  less  costly  ramifications  than  they  do  near  the  end  of  the  process. 

e  Measurements  of  both  process  and  product  are  appropriate,  but  they  have 
different  purposes. 

Process  measurements  are  directed  primarily  at  efficiency,  while 
product  measurements  are  intended  to  help  assess  quality. 

Process  measurements  are  manifested  in  terms  of  cost  and  time. 

Product  measurements,  at  least  at  this  point  in  time,  are  related 
primarily  to  the  structure  of  the  programs  themselves. 

I.       PROCESS  MEASUREMENTS  AND  ESTIMATION 

•  Cost  estimating  accuracy  has  improved  markedly  in  the  last  decade  for  those 
projects  where  it  has  been  rigorously  applied. 
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Not  only  total  costs  of  personnel  and  machine  time,  but  also  the  rate  at 
which  these  costs  are  incurred  over  the  lifetime  of  a  project,  can  be 
reliably  predicted  for  a  wide  variety  of  software  projects. 

A  single  cost  model  does  not  suffice  for  all  sizes  of  projects,  however: 

The  Putnam-Norden  model,  which  produces  a  Rayleigh  function  shape 
for  the  composite  deployment  of  manpower,  predicts  costs  well  for 
large  projects  (i.e.,  more  than  250  total  man  years  of  effort),  but 
overestimates  smaller  projects  by  a  factor  of  two  to  four  times. 

Other  models,  such  as  the  Boeing  model,  the  TRW  SCEP  model,  and  the 
RCA  PRICE  S  model,  are  more  accurate  on  systems  an  order  of 
magnitude  smaller. 

All  of  the  models  suffer  from  one  weakness  or  another,  such  as  the  inclusion  of 
subjective  factors  of  high  sensitivity,  instability  at  certain  size  ranges,  or  the 
requirement  for  inputs  that  are  difficult  to  understand  or  that  are  known  only 
after  completion  of  the  project. 

PRODUCT  MEASUREMENTS  AND  ESTIMATION 

Product  attributes  which  would  be  useful  to  measure  include  reliability, 
maintainability,  efficiency,  testability,  understandability,  and  adaptability. 

As  yet  there  no  consistent  or  quantitative  definitions  of  any  of  these 
attributes. 

There  are,  however,  a  number  of  structural  aspects  of  programs  which  appear 
to  influence  the  attributes  above,  and  which  can  be  defined  more  discretely. 
These  aspects  include: 

The  type,  degree,  and  information  content  of  coupling  between 
modules. 
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The  type  of  cohesion  within  each  nnodule,  i.e.,  the  nature  of  the 
relationship  that  holds  the  module  statements  together. 

The  simplicity,  or  inversely,  the  complexity,  of  each  module's  design. 

The  degree  to  which  the  scope  of  effect  of  each  module  does  not 
exceed  its  own  scope  of  control. 

The  independence,  or  "information-hiding"  characteristic,  of  each 
module.  .    .  '  ■ 

The  size  of  each  module,  particularly  whether  it  is  within  the  range  of 
30-60  logical  statements. 

•  Models  for  evaluating  the  "goodness"  of  a  program  are  to  date  less  successful, 
and  much  less  widely  applied,  than  models  of  cost  and  time  requirements. 

Variations  of  the  cyclomatic  complexity  metric,  a  concept  borrowed 
from  graph  theory,  appear  to  be  most  useful  in  assessing  complexity  or 
simplicity  of  a  given  design. 

Raw  size  still  appears  to  be  a  prime  determinant  in  quality  of  the 
software  product,  and  is  a  factor  in  nearly  every  quality  model. 

•  Very  few  non-academic  organizations  have  yet  adopted  a  quality  estimation  or 
assessment  technique  as  part  of  their  standard  practice  of  software  develop- 
ment. 

C.  TESTING 

•  Because  formal  proof  of  program  correctness  is  not  feasible  for  large  systems, 
verification  and  validation  depend  largely  upon  testing  of  certain  program 
attributes. 
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This  approach  suffers  from  the  weakness  that  it  can  demonstrate  only 
the  presence  of  defects,  not  their  absence. 

Thus  there  are  no  absolute  correctness  measures,  but  only  a  statistical 
probability  (highly  subject  to  economic  factors)  that  a  program  is 
correct. 

•  Performance  characteristics  more  directly  demonstrable,  but  testing  of  use- 
fulness, reliability,  and  robustness  has  rarely  been  addressed  other  than 
informally. 

•  Tests  of  correctness,  the  remaining  software  attribute,  currently  fall  into  the 
two  categories  of  path-oriented  testing  and  symbolic  execution. 

•  Path-oriented  testing  is  based  on  the  premise  that  unless  all  logical  paths 
through  a  program  are  exercised,  some  errors  may  remain  undetected. 

While  this  premise  is  necessary,  it  is  not  sufficient,  because  it  does  not 
allow  for  the  possibility  that  certain  data  may  exercise  a  path  without 
detecting  an  error. 

This  method  of  testing  is  valuable,  however,  in  providing  stronger 
assurance  of  test  coverage  than  testing  performed  in  a  less-disciplined 
way. 

•  Symbolic  execution  involves  using  not  actual  data  values  as  inputs,  but  symbols 
representing  classes  of  data  values. 

•  Because  one  test  can  stand  for  a  whole  range  of  values,  testing  the  entire 
input  domain  can  be  accomplished  with  fewer  than  the  total  number  of  input 
values. 

•  Limitations  to  this  method  involve  the  facts  that: 
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It  is  expensive. 

It  is  subject  to  errors  of  judgment  in  the  interpretation  of  results. 

It  is  difficult  to  express  some  forms  of  input,  as  well  as  the  whole  class 
of  non-numerical  algorithms,  in  symbolic  terms. 

A  third  approach  to  testing  depends  on  probability  theory  to  predict  how  many 
errors  may  still  remain  on  the  basis  of  the  number  of  errors  already 
discovered. 

When  this  number  reaches  a  sufficiently  small  value,  further  testing  is 
halted  as  being  uneconomical. 

The  approach  is  interesting,  but  results  to  date  have  been  highly 
variable. 

The  testing  techniques  most  widely  used  are  ad  hoc  in  nature,  and  probably 
address  the  wrong  subject.  That  is,  they  are  oriented  toward  coding,  while 
most  software  errors  are  design  and  specification  errors. 

Peer  design  and  code  reviews,  also  known  as  "program  inspections"  or 
"walkthroughs,"  have  been  most  effective  in  detecting  errors  at  both 
stages  of  development. 

Peer  reviews  are  widely  accepted  in  the  U.S.,  and  are  considered  to 
provide  a  very  cost  effective  supplement  to  data-oriented  testing 
approaches. 
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IV       FUTURE  DIRECTIONS 


•  The  design,  implementation  and  maintenance  of  information  processing 
systems  involves  a  number  of  creative  activities  that  are  highly  dependent  on 
human  intelligence,  experience,  skill  and  resourcefulness.  ' 

These  activities  are  not  amenable  to  automation,  so  improving  their 
productivity  must  rely  on  other  techniques:  personnel  selection, 
training  and  motivation,  organizational  and  environmental  factors,  and 
so  on. 

•  Many  aspects  of  design,  implementation,  validation  and  maintenance  are 
basically  clerical,  bookkeeping  or  repetitive  tasks. 

Such  tasks  could  all  be  automated,  with  productivity  improvements 
expected  as  a  result. 

In  fact,  most  such  tasks  have  already  been  automated  to  some  degree, 
as  the  previous  brief  review  of  tools  and  aids  has  clearly  demonstrated. 

•  The  underlying,  common  problem  of  all  existing  tools  and  aids  is  their  ad  hoc 
nature;  they  each  address  a  specific  area  independently  of  other  related  areas. 
For  example: 
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Existing  requirements  languages  have  no  interface  to  the  detail  design 
and  implementation  phase. 

Structured  design  and  analysis  methodologies  have  little  or  no  transition 
mechanism  into  coding. 

Structured  design  and  analysis  methodologies  address  the  entire  life 
cycle,  but  only  as  a  "checklist;"  i.e.,  without  tools  to  address  the 
substance  of  the  life  cycle  activities. 

Another  major  problem  is  the  scarcity  and  relative  ineffectiveness  of  tech- 
niques, tools  and  aids  to  influence  the  maintenance  activity  directly. 

Useful  tools  not  now  commercially  available  would  be: 

A  global  cross-reference  generator,  operating  across  the  entire 
application  system  of  main  program,  called  subroutines,  job 
control  statements,  utility  parameter  lists,  etc. 

A  mechanism  to  retroactively  populate  the  data  dictionary 
(related  to  the  cross-reference  generator). 

A  global  documentation  generator/editor  that  would  facilitate 
structured,  "reusable"  documentation. 

A  regression  test  harness  or  driver. 

The  absence  of  these  tools  leaves  a  rather  big  gap  in  productivity 
improvement,  since  INPUT  estimates  that  the  majority  of  the  life  cycle 
costs,  at  least  of  major  projects,  are  due  to  maintenance  rather  than 
development  activities. 

What  is  clearly  needed  is  a  system  to  integrate  the  automation  of  all  life  cycle 
activities  into  a  uniform,  compatible  and  communicating  set  of  techniques  and 
tools. 
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Using  the  existing  state  of  the  art  as  a  base,  without  requiring  any  revolu- 
tionary breakthroughs,  it  is  possible  to  visualize  such  a  system,  and  to  list  its 
major  features  and  characteristics. 


It  will  have  an  interactive  "workbench"  to  serve  the  needs  not  only  of 
coders,  but  also  of  system  specifiers,  system  designers  and  maintenance 
personnel. 

The  system  specifiers  and  designers,  working  interactively  via  their 
unique  "workbench,"  will  accumulate  the  specifications  and  overall 
design  of  the  system,  cast  in  a  "requirements  language." 

The  requirements  language  processor  will  store  the  elements  of  the 
system  specifications  and  design  in  the  same  data  base  and  data 
dictionary  that  will  eventually  be  used  for  the  operation  of  the  system 
being  designed. 

The  requirements  language  processor  will  perform  consistency  checks 
and  produce  documentation  to  serve  the  rest  of  the  system's  life  cycle. 

The  requirements  language  processor  will  produce  one  or  several 
alternate  "trial"  designs,  and  will  forecast  their  performance  under  a 
range  of  operating  assumptions. 

Specifiers  and  designers  will  think  in  terms  of  a  uniform,  company- 
wide  structured  design  and  analysis  methodology. 

a 

Detail  designers  and  coders,  supported  by  their  own  unique  "work- 
bench," will  convert  the  procedures  and  data  designated  in  the  speci- 
fications phase  into  executable  code,  using  a  very  high-level  language 
supported  by  the  appropriate  code  generator. 

They  will  be  able  to  search  a  large  library  of  previously  developed 
standard  functions  and  skeletons  by  context,  to  determine  which  of  the 
existing  modules  and  skeletons  already  satisfy  portions  of  the  new 
design. 


-  29  - 


It  may  even  be  possible  to  automate  such  search  directly  from  the 
system  specifications  output  of  the  requirements  language.  This  type 
of  automated  system  might  look  for  degrees  of  compatibility  and 
recommend  modules  that  match  desired  profiles  to  a  given  degree  (e.g., 
"looks  like  it  will  do  75%  of  what  you  want"). 

The  designers  and  coders  will  be  trained  in  structured  design  and  coding 
and  will  therefore  produce  code  in  a  uniform  style;  that  is,  they  will  do 
so  only  if  the  functions  they  want  are  not  in  the  reusable  code  library. 

Functions  that  appear  to  be  of  general  usefulness,  but  that  are  still 
missing  from  the  library,  will  be  marked  for  especially  exhaustive 
testing,  because  they  are  candidates  for  certification  as  "reusable"  in 
future  systems.  ~ 

For  relatively  small,  "run-of-the-mill"  systems,  designers  and  coders 
will  turn  to  a  number  of  menu-driven,  prepackaged  systems. 

Some  end  user  requirements  will  not  even  reach  the  DP  department, 
because  the  installation's  data  base  management  system,  with  its 
associated  query/retrieval  language,  will  allow  them  to  create  mini- 
applications  without  assistance. 

Throughout  the  entire  process,  the  activities  of  all  personnel  will  be 
guided  by  a  checklist  provided  by  a  system  development  methodology. 

Progress  reports  and  personnel/resource  loading  data  will  be  auto- 
matically produced  by  the  system's  automated  components.  For  this 
purpose,  these  components  will  be  able  to  exchange  data. 

Documentation  will  be  produced  automatically  from  the  data  in  the 
requirements  data  base  and  data  dictionary. 


-  30  - 


INPUT 


Both  plonned  and  unplanned  enhancements  to  the  system  will  be 
handled  as  "projects,"  although  they  will  not  require  the  complete  SDM 
checklist. 


There  will  be  an  automated  "version  control"  system  that  permits 
binary  modules  to  be  unambiguously  identified  with  the  source  code  and 
design  versions  that  produced  the  binary  modules.  This  system  will  also 
control  what  goes  into  the  "production"  version  of  the  system. 

.         Note  that  all  of  the  above  capabilities  already  exist  in  some  automated  form 
or  another. 


What  is  missing  is  the  "glue"  that  binds  the  individual  techniques  into  a 
uniform,  compatible,  communicating  system. 

The  other  missing  element  is  the  automation  of  program  validation  and 
checking. 

Clearly,  future  progress  must  then  proceed  along  two  lines  of  attack: 

Developing  integrated  systems  of  uniform,  communicating  tools. 

Developing  effective,  simple  tools  to  automate  program  validation  and 
checking. 

Looking  farther  into  the  future,  developments  in  very  high  level  languages 
(VHLL's)  show  great  promise  for  improving  the  productivity  of  software 
engineering,  if  the  combination  of  declining  hardware  costs  and  improved 
techniques  for  global  optimization  of  large  scale  programs  continues  to 
converge. 


Such  a  development  represents  an  evolution  and  extension  of  existing 
technology. 
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At  the  other  end  of  the  scale,  research  into  artifical  intelligence  is  suggesting 
ever  nnore  powerful  approaches  to  automatic  generation  of  programs  by  goal- 
directed  techniques. 

The  former  technique  seeks  to  make  the  programmer  more  effective,  while 
the  latter  approach  would  eliminate  the  programmer  and  work  directly  with 
the  end  user. 

Both  approaches  will  require  at  least  several  years  of  further  develop- 
ment before  they  are  suitable  for  widespread  application. 
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